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l.  zotbodoctioh 


This  paper  addresses  the  question  of  how  useful  military  software 
standards  are  for  maintaining  embedded  cooputer  software.  Our  discussion 
builds  on  previous  studies  of  this  topic  (Schneidewind ,  1982)  which 
involved  an  analysis  of  the  following  United  States  Kavy  publications: 

°  Military  Standard  (MIL-STD)  1679, 

°  Weapons  Specification  (WS)  8506,  and 

°  Tactical  Digital  Systems  Documentation  Standards,  SBCMVXNST  3S60. 1. 
(Mote:  Zt  is  recognize \  that,  technically,  only  the  first  document  is  a 
standard.  For  ease  of  exposition,  all  three  are  referred  to  as  "standards" 
in  this  paper.)  The  question  posed  by  the  previous  research  study  was: 

Could  these  standards,  accompanied  by  basic  program  documentation,  such 
as  a  listing,  provide  adequate  guidance  for  a  new  programmer  to  maintain 
software,  such  as  that  found  in  the  Trident  Command  and  Control  Subsystem? 
These  standards  were  reviewed  with  respect  to  the  following  criteria: 

°  design  approaches  for  achieving  good  maintainability, 

°  specification  and  documentation  requirements  for  achieving  good 
maintainability,  and 

°  testing  approaches  for  achieving  good  maintainability. 

With  soma  significant  qualifications,  it  was  concluded  that  these  standards 
were  adequate  for  maintenance  purposes.  However,  it  was  pointed  out  that 
these  standards  were  developed  for  use  in  design  and  not  for  maintenance 
specifically.  (The  interested  reader  may  find  the  details  in  the  references 
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which  haw  baan  citad.) 

Now,  an  axcallant  standard  would  rscognisa  tha  linkage  batwaan  soft- 
wara  design  and  aalntananca  and  would  specify  design  practices  that  are 
conducive  to  maintenance.  The  problem  seams  to  ba  that  standards  of  tha 
typa  which  have  baan  rafarencad  ware  developed  prior  to  tha  tima  whan 
maintenance  was  recognized  as  an  important  phase  of  tha  software  life 
cycle  and  prior  to  tha  realization  that  maintainability  must  ba  designed 
into  tha  software.  Software  standards  should  ba  revised  to  reflect  this 
important  concept.  Also,  advances  in  software  requirements  analysis  and 
dasign  methodologies ,  coupled  with  the  significant  use  of  microcomputers 
in  embedded  computer  systems,  have  lad  to  the  need  to  update  military 
software  scandaxds  to  reflect  the  realities  of  newer  design  and  progressing 
environments.  Improvement  in  dasign  approach  enhances  maintainability; 
tha  use  of  microcomputers,  on  the  other  hand,  presents  new  problems  for 
the  software  development  agency  due  to  the  limited  software  development 
tools  which  are  available  in  many  microcomputer  software  development 
facilities.  However,  it  is  an  open  question  as  to  whether  the  increased 
use  of  microcomputers  for  embedded  systems  is  siding  or  retarding  the 
production  of  maintainable  software.  Although  many  microcomputer  software 
production  facilities  are  law-level,  oriented  to  assembly  language  program¬ 
ming,  tha  trend  is  for  microcomputsr  software  to  be  developed  on  larger 
host  machines,  using  elaborate  program  developmant  tools  on  an  interactive 
basis,  and  down  loaded  to  a  developmant  systam  and  eventually  to  the  target 
machine  (Ziegler,  1982) .  This  trend  may  lssd  in  the  future  to  more  eaphasis 
on  chip  certification  and  less  on  software  validation.  As  contras tad  to 
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advances  in  software  design  and  programing  methodology,  it  is  not  clear  that 
software  standards  should  be  significantly  changed  just  because  cooputers 
get  smaller  and  programing  environments  change.  The  desirable  objectives 
of,  for  example,  producing  code  which  can  be  changed  without  upsetting 
the  rest  of  the  system  remains  valid  independent  of  the  particular  form, 
size,  speed  or  configuration  of  a  hardware-software  system. 

Transcending  the  aspects  of  improved  software  design  methodology  and 
changing  computer  technology,  is  the  need  to  trace  both  errors  in  the 
software  and  design  decisions  (which  many  times  are  related  to  errors)  to 
the  pertinent  technical  information*  The  need  for  traceability  is  independent 
of  software  design  methodology  and  the  particular  computer  technology 
which  is  used  in  a  system.  However,  proper  use  of  methodology  and  technology 
can  greatly  improve  traceability,  particularly  with  regard  to  identifying 
the  effects  of  changes  to  the  software. 

Within  the  context  of  the  question  posed  at  the  beginning  of  this 
section,  we  examine  the  usability  of  military  software  standards  in  the 
ensuing  sections  with  respect  to  the  following  areas : 

0  requirements  analysis  methodologies ; 

°  microcomputer  software  development;  and 
9  traceability. 

We  conclude  with  recommendations  concerning  the  effective  utilisation  of 
these  standards  in  an  environment  of  changing  methodology  and  technology. 
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2.  EFFECTS  OF  BBOPIREMEHTS  AHALYSIS  SYSTEMS  OH  SOFTWARE  3TAMDARDS 

On*  of  the  major  efforts  to  improve  the  quality  of  software  has  focused 
on  the  development  of  formal  software  requirements  analysis  methodologies 
(Alford,  1977;  Bell,  1977;  Ross,  1977;  Teichroew,  1977).  Objectives  of 
these  and  related  systeas  are  the  following) 

°  iaproved  quality  of  documentation  with  regard  to  precisian,  consist¬ 
ency  and  coapleteness) 

0  f  oread,  methods  of  specifying  requirements ,  usually  involving  the 
use  of  a  language  or  format  for  expressing  requirements  (Liskov, 
1975);  and 

0  separation  of  system  functions  so  that  related  functions  appear  in 
the  same  nodule  and  unrelated  functions  appear  in  different  modules, 
resulting  in  the  creation  of  independent  modules  (Myers ,  1978) . 

A  major  ingredient  of  requirements  analysis  methodologies  is  computer- 
aided  analysis,  consisting  of  the  following  components:  a  language  for 
expressing  requirements;  a  data  base  for  storing  requirements  and  specifi¬ 
cations;  an  analysis  and  retrieval  system  for  checking  requirements 
consistency  and  coapleteness;  and  various  types  of  graphics  terminal  and 
hardcopy  outputs  (Bell ,  1977) .  The  emphasis  of  these  systems  is  a  language 
aimed  at  achieving  formalism  and  consistency  of  expressing  requirements. 
These  methodologies  do  not  address  to  a  great  extent  strategies  for 
translating  requirements  into  a  software  design. 

An  effort  where  design  strategies  and  requirements  analysis  techniques 
are  directed  toward  confining  the  effects  of  changes  to  software  (hence. 
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improving  maintainability)  is  the  project  of  the  Naval  Research  Laboratory 
(Britton,  1981;  Heninger ,  1978,  1980;  Parker,  1980)  to  rewrite  the  soft¬ 
ware  for  the  A-7E  Aircraft,  using  the  principles  of  information  hiding, 
separation  of  concerns  and  abstract  interfaces  (Parnas,  1972,  1978;  Hestor, 
1981;  Britton,  1981) .  Central  to  this  effort  is  the  method  for  decomposing 
modules.  The  method  proposed  by  Parnas  (Parnas,  1972)  is  the  following: 

°  every  module  in  the  decomposition  process  is  characterized  by  design 
decisions  which  are  hidden  from  all  other  modules  (the  information 
hiding  principle) ;  this  criterion  does  not  decompose  the  system 
into  modules  on  the  basis  of  the  time  sequence  of  processing  the 
modules;  and 

°  elements  that  are  likely  to  change  are  identified  and  incorporated 
into  separate  modules  (device  interface  modules)  in  order  to  mini¬ 
mize  the  effects  of  device  changes  on  user  modules. 

Myers  (Myers,  1978),  among  others,  has  sounded  a  similar  theme.  He 
recommends  that  modules  should  be  partitioned  so  that  relationships  between 
modules  are  minimized.  In  Myer's  terms,  this  results  in  high  module  strength 
and  weak  module  coupling,  and  leads  to  the  desirable  result  of  module 
independence.  A  major  objective  of  these  approaches  is  to  reduce  the 
ripple  effect  of  software  changes  (that  is,  the  effect  on  modules  external 
to  the  changed  module) . 
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2.1  STATUS  OP  STANDARDS  RELATIVE  TO 


HJIggMEgTS  ANALYSIS  SYSTEMS 


What  is  the  status  of  the  standards  (1679,  8506,  3560.1)  relative  to 
specifying  the  use  of  requirements  analysis  methodologies  and  design 
techniques  (e.g.,  methods  for  module  deconposition) ?  MIL- STD- 16 79, 

Section  5.2,  states  that  the  design  shall  be  a  hierarchical  structure  with 
the  highest  level  of  control  logic  residing  at  the  top  of  thr  erarchy 
and  computation  functions  residing  at  the  lower  levels.  As  ad  by 

Myers  (Myers,  1978),  the  objective  is  not  simply  partitionin  Jules  into 

a  hierarchy,  but  partitioning  so  that  each  module  is  as  inde  -  it  of 
other  modules  as  possible.  This  procedure  will  result  in  confining  the 
effects  of  change  and,  hence,  make  the  software  more  maintainable.  In 
addition,  as  indicated  by  Schneidewind  (Schneidewind,  1982,  NPS-54-82-002)  , 
although  the  change  in  reporting  and  control  procedures  specified  by  1679 
is  excellent  in  Section  5.11.2,  the  coverage  is  inadequate  regarding 
separation  of  software  functions  by  anticipated  degree  of  change.  With 
regard  to  WS  8506,  it  makes  brief  mention  of  describing  major  functions 
and  the  dependency  among  functions  in  Section  5.2.  This  reference  does 
not  elaborate  on  why  or  how  the  information  is  to  be  used  (Schneidewind, 
1982,  NFS- 5 4-82 -002) .  An  important  use  of  the  information  would  be  for 
decomposing  a  system  into  modules  and  for  the  related  purpose  of  achieving 
module  independence.  The  situation  is  worse  in  the  case  of  SECNAVINST 
3560.1.  This  document  is  notable  for  the  great  amount  of  detail  presented 
pertaining  to  function  and  interface  descriptions,  data  exchange,  program 
resource  budgets,  etc.  (Schneidewind,  1982,  NPS- 59-8 2-00 3) .  However, 
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there  is  an  absence  of  material  dealing  with  designing  for  change . 

In  addition  to  the  above  gaps  in  coverage,  the  standards  pre-date  the 
use  of  software  requirements  analysis  systems,  such  as  those  described 
by  Alford  (Alford,  1977).  Naturally,  the  older  the  standard,  the  more 
obsolete  it  is  relative  to  advances  in  requirements  analysis  methodologies 
and  software  design.  So  these  remarks  should  not  be  construed  as  criticism 
of  the  standards,  but  as  indications  of  the  need  to  consider  updating  the 
standards  for  the  purpose  of  bringing  them  into  line  with  software  engineer¬ 
ing  techniques  which  look  quite  promising.  It  is  necessary  to  emphasize 
that  methods  proposed  by  Pamas,  Myers,  Teichroew  and  others  have  not 
reached  the  stage  of  accepted  practice  by  a  large  segment  of  the  software 
engineering  community.  For  one  thing,  there  must  be  further  demonstration 
of  improvements  in  software  maintainability  on  large  systems  before  these 
procedures  will  graduate  to  the  status  of  standard  practice.  However,  we 
contend  that  the  approach  in  standards  development  should  bo  t j  lead  rather 
than  to  follow  developments  in  software  engineering.  There  is  obviously 
more  risk  associated  with  this  policy,  but  its  successful  implementation 
can  prevent  a  standard  from  being  obsolete  before  it  is  even  issued. 

In  summary,  with  regard  to  the  areas  of  requirements  analysis  and 
software  design,  the  standards  are  weak  and  in  need  of  upgrading  to  include 
the  following  requirements: 

0  decomposition  of  a  system  into  modules  for  the  purpose  of  confining 
the  effects  of  software  changes  by  using  techniques  such  as: 

-  hiding  device  characteristics  from  user  programs  and, 

-  designing  modules  so  that  related  elements  are  contained  in 
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the  same  module  and  unrelated  elements  are  contained  in  different 
nodules  (high  module  strength  and  low  nodule  coupling) ;  and 
employment  of  a  requirements  analysis  system  for  the  purposes  of: 

-  standardising  the  language  in  which  requirements  are  stated,  and 

-  providing  computer-aided  tools  for  storing,  analysing  and  retrieving 
requirements  to  ensure  consistency  and  completeness . 


3.  THE  EFFECT  OF  MICEOCOHFOTEgg  Oil  STOUfDMDg  DEVELOPMENT 

As  suggested  in  Section  1,  standards  developme nt  should  ba  independ- 
ant  of  tha  charactaristics  of  tha  hardware  and  software  employed  in  an 
application.  A  standard  should  raquira  tha  davalopar  to  employ  sound 
software  enginaaring  practices,  these  techniques  become  ' sound*  by  evolving 
from  theory  to  standard  practice  through  a  process  of  proposal,  debate, 
demonstration ,  use,  concensus  and  acceptance,  this  process  should  not  be 
influenced  by  whether ,  for  example,  an  application  is  implemented  in  a 
centralised  main  frame  or  a  distributed  microcomputer  system,  the  aspect 
that  is  affected  by  the  choice  of  technology  is  the  ability  of  the  developer 
to  meet  the  standard  (e.g. ,  conforming  to  a  requirement  for  using  struc¬ 
tured  programming  with  assembly  language  versus  high  level  language) .  For 
example,  if  crude  program  development  and  test  tools  are  used  for  imple¬ 
menting  microcomputer  software,  or  any  software  for  that  matter,  traceability 
will  be  difficult  to  achieve.  More  will  be  said  about  traceability  in  a 
later  section. 

Concern  about  the  peculiarities  of  microcomputer  software  development 
may  evaporate  in  the  near  future.  As  mentioned  in  Section  1,  the  trend  in 
microcomputer  software  development  is  toward  using  the  types  of  tools  which 
have  been  used  for  some  time  in  the  minicomputer  and  mainframe  areas.  For 
example,  if  we  compare  two  publications  which  are  only  one  year  apart  (Ogdin, 
1980)  and  (Markowitz,  1981),  we  find  that  the  former,  in  describing  micro¬ 
computer  programming  environments,  stresses  he xi decimal  coding,  prototyping 
systems,  computer  evaluation  kits,  portable  front  panels,  single  board 
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computers  and  microcomputer  davalopnent  ays  tans.  In  contrast,  Markowitz's 
article  describes  the  architecture  of  the  iAPX  286  in  tarns  of  memory 
management,  segmented  memory,  protection,  and  various  priviladga  levels  - 
characteristics  of  large  machines*  Zeigler  (Zeigler,  1981)  talks  about 
extensions  to  the  ADA  language  which  INTEL  has  developed  in  support  of 
the  432  architecture. 

Hone  of  the  standards  makes  reference  to  the  use  of  microcomputers. 
Ibis  would  obviously  be  the  case  for  3560.1  and  8506,  since  their  publi¬ 
cation  pre-dated  significant  use  of  microcomputers.  Although  1679  was 
published  during  the  era  of  microcomputers,  mentioning  the  use  of  this 
technology  in  the  standard  would  have  been  inappropriate.  As  stated  by 
Cooper  (Cooper,  1981),  in  describing  the  development  of  1679,  the  single 
most  important  rule  of  a  MIL- STD  is  that  it  can  only  specify  what  is 
required,  not  how  to  satisfy  a  requirement.  However,  it  must  be  noted 
that  1679  does  not  seem  to  be  entirely  faithful  to  this  rule,  since  it 
calls  for  the  use  of  structured  programing  constructs  (Section  5.3),  and 
top  down  design  and  high  order  languages  (Section  5.5),  as  examples  of 
many  "how  to"  provisions. 

Based  on  the  reasons  given  in  this  section,  we  conclude  that  the 
standards  should  not  be  modified  to  incorporate  provisions  that  deal  with 
the  development  of  microcomputer  software  for  embedded  computer  systems. 
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4.  APPROACHES  FOR  IMPROVING  TRACEABILITY  OF  STANDARDS 


A  prerequisite  for  achieving  traceability  and,  hence,  maintainability , 
is  to  have  planned  for  the  software  to  change  when  it  was  designed  and  to 
have  designed  the  software  correspondingly,  so  that  changes  can  be  easily 
traced  through  the  documentation  in  order  to  identify  the  relevant  inputs, 
outputs,  data  base,  modes  of  operation,  conditions,  etc.  The  A-7E  Aircraft 
documentation  (Heninger,  1978)  does  a  good  job  of  providing  traceability 
because  it  was  designed  with  change  in  mind.  Seas  of  the  formats  which 
are  useful  for  achieving  traceability  are  the  following » 

0  Event  Tables  which  relate  nodes,  events,  and  actions; 

0  Condition  Tables  which  relate  modes,  conditions  and  actions  or 
values;  and 

0  Selector  Tables  which  relate  modes  and  mutually  exclusive  charac¬ 
teristics  of  modes. 

In  the  above,  the  following  meanings  apply: 

°  mode  -  system  state; 

0  condition  -  expression  whose  value  is  true  or  false  and  characterises 
the  system  for  a  measurable  tins; 

°  event  -  a  condition  which  changes  from  true  to  false  or  vice  versa 
at  a  specific  moment  in  time; 

°  action  -  evaluation  of  a  function;  and 
°  value  -  expression  or  output  data  item  value. 

In  this  system  of  documentation,  if  an  event  (e.g.,  ground  distance 
to  a  reference  point)  were  to  change  when  the  radar  updata  nods  is  entered. 
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it  would  bo  possible  to  ascertain  tho  foot  that  this  combination  affects 
an  action  takon  by  tho  pilot  relative  to  cursor  enable  (output  data  item) . 
In  general,  design  decisions,  nodule  decomposition  and  nodule  dependencies 
are  node  explicit  in  the  system  of  software  design  and  documentation. 

Other  useful  aspects  of  the  documentation  include  a  dictionary  of  commonly 
used  tens  and  a  section  dealing  with  subsets  -  a  part  of  the  system 
which  is  isolatable  from  the  total  systea,  performs  part  of  the  services 
provided  by  the  total  system  and  uses  less  computer  resources  than  the 
total  systen.  One  of  the  ideas  of  subsets  is  to  be  able  to  reassemble  a 
smaller  systea  and  thereby  save  on  resources  if  the  entire  systea  is  not 
utilised  (e.g. ,  a  particular  weapon  is  not  available  or  used) . 

Weaknesses  in  this  system  seem  to  lie  in  the  areas  of  tracking  changes 
in  outputs  to  inputs  and  data  bases,  where  applicable ,  and,  in  sons  cases, 
lack  of  clarity  of  definitions  as  they  relate  to  various  tables.  Also, 
although  we  subscribe  to  the  objectives  of  information  hiding,  which 
provides  the  underpinning  of  the  A-7e  project,  it  is  our  opinion  that  the 
design  procedures  and  terminology  which  are  necessary  to  implement  infor¬ 
mation  hiding  could  be  confusing  to  software  engineers.  We  prefer  to 
think  of  the  process  of  requirements  analysis  as  making  requirements 
explicit ,  rather  than  hiding  certain  ones,  and  to  only  embody  a  requirement 
in  a  module  when  the  requirement  is  relevant  to  that  module »  otherwise, 
the  requirement  is  implemented  in  a  nodule  where  it  is  relevant.  Require¬ 
ments  Which  are  common  to  two  or  more  modules  are  contained  within  a 
separate  module,  rather  than  within  the  given  modules  themselves.  Addi¬ 
tionally,  requirements  which  are  likely  to  change  should  be  quarantined 
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and  placed  in  a  limited  number  of  modules  rather  than  being  spread  across 
many  modules. 

Nevertheless,  on  the  whole,  the  A-7B  Aircraft  project  and  a  related 
project  (Hester,  1981)  would  provide  an  excellent  model  for  revising  the 
standards  to  incorporate  software  design  practices  which  specifically 
address  the  need  to  account  for  future  change  to  the  software.  This  would 
be  a  particularly  powerful  approach  if  coupled  with  the  use  of  one  of  the 
requirements  analysis  systems  (Ross,  1977)  for  providing  coaputer-aided 
requirements  analysis  tools  and  for  supporting  the  requirements  analysis 
which  must  precede  the  software  design. 

The  primary  author  of  MIL-STD  1679  (Cooper,  1981)  feels  that  with 
only  two  years  use,  it  would  be  premature  to  revise  it.  However,  neither 
1679  nor  the  other  standards  are  strong  in  the  vital  area  of  traceability 
(Schneidewind,  1982).  We  feel,  therefore,  that  because  the  volatility  of 
software  is  so  great  and  affects  maintenance  so  significantly,  that  a 
standard  must  explicitly  provide  for  change  in  the  design  process  in  • 
order  to  achieve  traceability  in  the  maintenance  phase.  Note  that  this 
characteristic  of  a  standard  is  not  the  same  thing  as  a  change  control 
procedure,  which  is  a  part  of  1679.  To  use  a  medical  analogy,  the  recommended 
approach  involves  using  preventive  medicine  early  in  the  life  of  a  system 
in  order  to  avoid  emergency  surgery  at  a  later  date. 
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5.  CCBCL0SI0W8  AMP  HMCaMBIOKgXOM 

Hum  important  areas  relative  to  software  standards  have  been 
considered  which  potentially  impact  on  software  eal ntai nabl lity  > 

(1)  requirements  analysis  and  software  design  methodologies ; 

(2)  microcomputer  software*  and 

(3)  traceability. 

It  is  concluded  that  (1)  and  (3)  should  be  improved  in  SBCMAVXN8T  3560.1, 
NS8506  and  MH/-STD  1679  and  that  (2)  is  not  appropriate  for  inclusion  in 
a  standard. 

Furthermore,  it  is  recommended  that  A7-E  Aircraft  software  redesign 
project  be  used  as  a  model  for  improving  the  standards  relative  to  (1)  and 
(3). 
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